In the last two decades computers have developed into sophisticated machines having powerful processors and large amounts of memory and local data storage. A modem computer has installed thereto a large operating system, which today includes not only low-level functions for accessing input, output and storage devices, but additionally libraries providing common functions to applications, graphical windowing systems, and applications to perform administrative functions, data access functions, and even multimedia and entertainment functions. The common practice of using applications requires the installation of an application's executable, configuration and data files to local storage, although some applications and systems extend this to use of network drives as well. Today's computers also multitask, and permit more than one application to be installed and executed thereon concurrently. This sophistication in the operating system in combination with the large number of potential applications from diverse sources has made the administration of a typical modem computer more difficult.
With the advent of graphical operating systems, users were offered a way to visually interact with a computer. This visual interaction made possible a new heirarchical organization to the computer presentation, typically including a top-level presentation, for example a ‘desktop’ with a top level ‘start’ menu, and further including sub-presentations such as application windows. Executing applications under that mode may be performed by acting on icons and menu items, relieving the user from the burden of having to know the logical location of items in a filesystem to use them. These icons, shortcuts, links and menu items all point to an executable or other object at their true reference points. If the reference object is moved to a different location in the filesystem heirarchy, the link to the object becomes broken and non-functional; in some operating systems the system may attempt to resolve the new location of the object and fix the link.
In personal computers of the early to mid-1980s, applications and data were typically stored to a floppy disk, with little to no other non-volatile storage available to programs. Those disks could be transported between computers of the same type, thereby making those applications portable. The execution of those applications, however, was from the command line, which required some user expertise. A user, for example, might need to know that an application's executable was located on drive ‘0’ or ‘a:’. Should an application disk be inserted to a second drive, the application might be required to be reconfigured to reference data and configuration objects on that second drive. The computer and operating system makers of the time largely left the problem of application mobility (moving an application to a different drive or location) unaddressed, which required users to maintain many applications in static locations even though stored to floppy disks.
Other types of portable storage have been used in the past. One early example was a cartridge including a read-only memory and a card-like interface mating to a socket, for example in a game console. Those cartridges contained no file-system, but rather were presented as instructions and data at particular addressible memory locations. In addition to floppy disks, mentioned above, high density magnetic media cartridges have been used, for example “Zip” disks. The improvement therein related mainly to the amount of data that could be stored on the portable media. Other examples include optical and magneto-optical disks, some of which are commonly known as CDs and DVDs. The advent of these permitted the cheap distribution of software and data, supplanting the use of floppy diskettes and permitting the growth of software applications to many megabytes. Those software makers have taken advantage of the increasingly large amounts of local hard drive storage for applications, and have largely not attempted installations other than to a local hard drive. Today, nearly all software packages perform an installation step in which the application's files are installed to a local hard drive of a computer.
Most recently, devices have become available which utilize a non-volatile random-access memory (NVRAM); the recent advances of integrated circuit technology permitting manufacture of such a device of a size to permit a person to carry hundreds of megabytes of data in a package that will easily fit into a pocket, purse or briefcase. Notable form-factors include Compact Flash, Secure Digital, Memory Stick and several others, which incorporate a type of NVRAM referred to as “Flash” memory, which has become relatively inexpensive to produce. Those form-factors have included interfaces designed typically for small electronic devices such as digital cameras or personal data assistants (PDAs). More recently, devices have become available which include a Universal Serial Bus (USB) controller, by which the these devices are made accessible as file storage “drives” to more recent computers having USB ports without an additional interfacing device, provided that certain drivers are installed to the computer or included in the operating system. Most recently, computers have been manufactured that include slots for interfacing with a flash card and the necessary electronics and drivers to access the flash memory as an external hard drive.
Applications can be stored to a portable flash memory device, but in present systems the applications files are viewed in a separate logical location than the files and directories of the base operating system, as no attempt is made to integrate the applications with the applications of the operating system. Indeed, prior systems provide no direct linkage to applications, registry changes, and changes to a base operating system whereby the applications on a removable storage device may be integrated in the base system. Because of the difficulty of this integration, the present use of portable storage devices is largely restricted to the storage of application data, accessible to applications installed to a host computer system.
In all of the above examples, the most convenient uses of applications are either installation of the application to a local hard drive or use of applications stored on portable media in a known or determinable position in the filesystem heirarchy of the computer. In the latter use, the application might be used on more than one computer, provided that the user has sufficient expertise to configure the application and operating system with any necessary icons, drivers, and directory locations.
In an additional method, some operating systems include the function of automatically running an executable at the time of media insertion. This is usually done by testing for the presence of a file with a specific filename, for example “autorun.exe”, which is executed by an operating system process when media insertion is detected. This method is sometimes used to run an application installer, or alternatively to run a main application stored on a compact disc.
From the early days of personal computers to the present time, bootable portable media disks and other media forms have been used to provide functionality to a computer without a requirement of a hard disk containing an operating system. For example, several computer makers have included a “disk operating system” (DOS) on a floppy disk, which provided common functions for interactions with the disk and other computer functions as well as a shell environment for basic human interaction. Even earlier systems used reels of tape and even stacks of punched cards to boot a computer, although most of those would hardly be considered portable by today's standards. Modem software makers may create bootable compact discs, for example to install an operating system freshly to a computer. Other makers may create operating systems that run entirely from the compact disc, and may not require that local storage of any kind be present.
One example of such a system is the Mandrakesoft “Move” Linux CD presently available from Mandrakesoft of Paris, France. In that system, a user may connect a USB flash drive to a computer booted from the Move CD, thereby providing a location to store user data. The CD and the flash drive can be caffied to a different computer, which can be booted using the CD and flash drive, thereby providing access to the user data. The user, however, has little choice in what applications are available in that system, as the CD is distributed with a fixed application set intended for general use.
Other uses of removable media have included synchronization of data on a local hard disk with the media, for example the “Migo” flash media product from PowerHouse Technologies Group, Inc. of San Ramon, Calif. Such a product may include applications installed thereto which can be run by a host computer, for example, when the media is connected to a computer that supports automatic execution. Even so, those applications can be expected to appear separately from the host computer's installed applications.
Additionally, prior computing systems have been susceptible to application conflicts with the host operating system (OS) and other applications. When an application is installed to an OS, a number of globally accessible files are often placed to the computing system, including for example shared libraries and system configuration. Those shared libraries are often provided in different versions, with applications requiring one version or another. A mismatch between a library version and a version required by an application sometimes results in that application crashing, becoming inoperable, or exhibiting other errors. Shared configuration elements are sometimes globally available to applications, which may write a favored configuration thereto. Following a write to that configuration other applications may be unable to read the configuration properly, or may be unable to function under a new specified configuration. Thus it is that following the installation of an application to a computer, other applications may stop working.
Installing a number of applications to a computer can be something of a black art. An administrator may, with good intentions and understanding, install several applications to a computer. Upon testing an installation or during use, the administrator or a user may discover that one or more applications operate errantly or not at all. It is usually not apparent which applications are in conflict. The administrator may enter a procedure in which applications are uninstalled from the computer in a process of elimination to find the offending applications. Sometimes de-installation programs do not remove all installed files, in which that procedure may fail to locate the problem. The administrator is then required to continue by creating a clean (or “virgin”) installation, and installing applications one at a time until the problem is located.
When applications are found to conflict, a choice must usually be made as to which one will be installed. One of the applications is sometimes installed to a different computer to avoid the conflict. If conflicting applications must be installed to a single computer, a new version of at least one of the applications must be sought and purchased from the software vendors. A non-conflicting version may not be available, especially if a vendor is small, not supporting the application, or no longer in business.
Snapshot utilities are available, which generally operate to create a database of all files and registry settings on a computer. Prior to installing an application, a snapshot is taken of the files and registry settings. The application is then installed, and tested. If the application fails to work satisfactorily, the system can be restored by comparing the existing files and registry settings against the snapshot and removing installed files and otherwise restoring the system as before. Snapshot utilities have several limitations. First, if a newly installed application causes a prior installed application to fail, it is often not possible to simply revert to a snapshot made prior to older application installation, especially if there have been other applications installed in the interim. The administrator may be required to revert back to the earlier snapshot, and then re-install the intervening applications and the new application. Additionally, there are usually a limited number of snapshots that can be stored, and thus a required snapshot may not have been retained when found to be needed.
Likewise, a system may be restored to an earlier state if backups have been made. That restoration process, however, usually involves a significant amount of time and destroys all data recorded to the system after the time of the backup.
Another method involves recording a series of changes (or “diffs”) to a buffer. Using that method a system can be restored back to a point in time by reverse application of the diffs to the file system back to the selected point in time. That method typically requires a fixed amount of disk space for the diff buffer, which becomes unavailable for regular use. As the buffer becomes full, the only way to continue to record diffs is to overwrite older diffs. Because of this limitation, the method can only restore a system back to a date for which diffs remain available. In addition, this method requires three disk operations per write request: one to read the existing disk information, one two write the diff, and one to write the original request. This method is therefore processor and disk intensive.
The Microsoft Windows ME™ OS includes a feature called “System Restore”. That system is essentially a snapshot system, and only backs up files related to the OS and installed applications (not user files).
A current practice of maintaining computers is to image the hard drive of a computer while in a working state. If the computer becomes unstable, or if undesirable content appears on the computer, the computer's drive is restored using the earlier made image. This practice is lacking in that all changes made following the image creation are wiped off the system when the computer is restored, including user files and other applications.
Also, some applications are not provided with an uninstall program. To de-install those applications an administrator is required to know where the application files and settings reside in the system, and remove them manually.